IRIX Base Documentation 2001 May/SGI IRIX Base Documentation 2001 May.iso/usr/share/catman/p_man/cat3/ifl/IFL.z/IFL

Text File | 1998-10-20 | 31.2 KB | 661 lines

IIIIFFFFLLLL((((3333))))            IIIImmmmaaaaggggeeee FFFFoooorrrrmmmmaaaatttt LLLLiiiibbbbrrrraaaarrrryyyy CCCC++++++++ RRRReeeeffffeeeerrrreeeennnncccceeee MMMMaaaannnnuuuuaaaallll             IIIIFFFFLLLL((((3333))))



NNNNAAAAMMMMEEEE
     IIIIFFFFLLLL - overview of Image Format Library


SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
     The Image Format Library (IFL) is a library for opening, reading, writing
     and creating image files in a format independent manner. IFL consists of
     a library developed in C++. An interface library for C programmers is
     also provided.  IFL includes support for the FIT, GIF, JFIF, Photo CD,
     PNG, PPM, SGI, TIFF and numerous other file formats.  It also supports
     reading and writing raw image data in a fairly flexible manner.  It is
     designed to be very easy to use with a straight-forward mechanism support
     user-defined file formats.


GGGGEEEETTTTTTTTIIIINNNNGGGG SSSSTTTTAAAARRRRTTTTEEEEDDDD
     To open a file and read it into memory you can write C++ code like the
     following:

          #include <ifl/iflFile.h>

          // open the file named by 'filename'

          iflStatus sts;
          iflFile* file = iflFile::open(filename, O_RDONLY, &sts);
          if (sts != iflOKAY) { /* handle the error */ }

          // read the entire image (just the first plane in z if image has depth)
          // into a buffer of unsiged chars

          iflSize dims;
          file->getDimensions(dims);
          unsigned char* data = new unsigned char[dims.x*dims.y*dims.c];
          iflConfig cfg(iflUChar, iflInterleaved);
          sts = file->getTile(0, 0, 0, dims.x, dims.y, 1, data, &cfg);
          if (sts != iflOKAY) { /* handle error */ }

          // close the file
          file->close();


     or equivalently in C you could write:

          #include <ifl/iflCdefs.h>

          /* open the file named by 'filename' */

          iflStatus sts;
          iflFile *file;
          iflSize dims;
          unsigned char *data;
          iflConfig* cfg;



                                                                        PPPPaaaaggggeeee 1111






IIIIFFFFLLLL((((3333))))            IIIImmmmaaaaggggeeee FFFFoooorrrrmmmmaaaatttt LLLLiiiibbbbrrrraaaarrrryyyy CCCC++++++++ RRRReeeeffffeeeerrrreeeennnncccceeee MMMMaaaannnnuuuuaaaallll             IIIIFFFFLLLL((((3333))))



          file = iflFileOpen(filename, O_RDONLY, &sts);
          if (sts != iflOKAY) { /* handle the error */ }

          /*
              read the entire image (just the first plane in z if image
              has depth) into a buffer of unsiged chars
          */

          iflFileGetDimensions(file, &dims);
          data = (unsigned char*)malloc(dims.x*dims.y*dims.c);
          cfg = iflConfigCreate(iflUChar, iflInterleaved, 0, NULL, 0, 0);
          sts = iflFileGetTile(file, 0, 0, 0, dims.x, dims.y, 1, data, cfg);
          if (sts != iflOKAY) { /* handle error */ }

          /* close the file */
          iflFileClose(file, 0);


     This simple example opens a file in any image format supported by IFL.
     The open function returns a pointer to an iflFile object which is IFL's
     abstraction for accessing image files. This object is described further
     below and in the iflFile(3) man page. The file object is then used to
     read the image's data it into memory. The iflConfig object is used to
     specify that that data should be read in the file's _o_r_i_e_n_t_a_t_i_o_n, but with
     the pixels forced to unsigned char format and _i_n_t_e_r_l_e_a_v_e_d ordering.

     Creating and writing an image file is just as simple:

          // create a one-channel, unsigned char image file
          iflSize dims(width, height, 1);
          iflFileConfig fc(&dims, iflUChar);
          iflStatus sts;
          iflFile* file = iflFile::create(filename, NULL, &fc, NULL, &sts);
          if (sts != iflOKAY) { /* handle the create error */ }

          // write a tile of data to it
          sts = file->setTile(0, 0, 0, width, height, 1, data);
          if (sts != iflOKAY) { /* handle error */ }

          // make sure the data gets written out to disk (or you can close here)
          sts = file->flush();
          if (sts != iflOKAY) { /* handle error */ }


     or equivalently in C you could write:

          iflFile *file;
          iflFileConfig *fc;
          iflStatus sts;
          iflSize dims;

          /* create a one-channel, unsigned char image file */



                                                                        PPPPaaaaggggeeee 2222






IIIIFFFFLLLL((((3333))))            IIIImmmmaaaaggggeeee FFFFoooorrrrmmmmaaaatttt LLLLiiiibbbbrrrraaaarrrryyyy CCCC++++++++ RRRReeeeffffeeeerrrreeeennnncccceeee MMMMaaaannnnuuuuaaaallll             IIIIFFFFLLLL((((3333))))



          dims.x = width;
          dims.y = height;
          dims.z = 1;
          dims.c = 1;
          fc = iflFileConfigCreate(&dims, iflUChar, 0, 0, 0, 0, NULL);
          file = iflFileCreate(filename, NULL, fc, NULL, &sts);
          if (sts != iflOKAY) { /* handle the create error */ }

          /* write a tile of data to it */
          sts = iflFileSetTile(file, 0, 0, 0, width, height, 1, data, NULL);
          if (sts != iflOKAY) { /* handle error */ }

          /* make sure the data gets written out to disk (or you can close here) */
          sts = iflFileFlush(file);
          if (sts != iflOKAY) { /* handle error */ }


     The code fragment above creates a one-channel file with the specified
     width and height and unsigned char data type.  The rest of the attributes
     default to a format-preferred value.  The file format will be inferred
     from the file name suffix.  (It is also possible to explicitly give a
     format, and to inherit attributes from another iflFile.)  This example
     then writes a tile of data to the file.  It assumes the data buffer is
     the size and data type as the image created. It is also possible to do
     automatic conversion on the sssseeeettttTTTTiiiilllleeee() operation.  Always be sure to flush
     or close the file when you are done writing data to it or the disk file
     may not be correctly written.

     Be aware that IFL doesn't scale the data when converting data types, so
     you'd better be sure to pick a data type large enough to hold the range
     of data values in the image file; you can use the ggggeeeettttSSSSccccaaaalllleeeeMMMMiiiinnnnMMMMaaaaxxxx() and
     ggggeeeettttSSSSttttaaaattttMMMMiiiinnnnMMMMaaaaxxxx() methods of iflFile to check the range of values.  Also,
     IFL doesn't do any color model conversions; if you need that level of
     functionality you may want to use the ImageVision Library (IL) that is
     layered on top of IFL.

     The following section on image attributes defines some of the terms just
     used such as _o_r_i_e_n_t_a_t_i_o_n and _d_i_m_e_n_s_i_o_n _o_r_d_e_r_i_n_g.


   EEEExxxxaaaammmmpppplllleeee ssssoooouuuurrrrcccceeee
     If you install ifl_dev.sw.gifts, you can examine the source code provided
     in /_u_s_r/_s_h_a_r_e/_s_r_c/_i_f_l/_a_p_p_s for more examples of using IFL.


IIIIMMMMAAAAGGGGEEEE AAAATTTTTTTTRRRRIIIIBBBBUUUUTTTTEEEESSSS
     The Image Format Library characterizes images according to the common
     attributes described in the following sections.







                                                                        PPPPaaaaggggeeee 3333






IIIIFFFFLLLL((((3333))))            IIIImmmmaaaaggggeeee FFFFoooorrrrmmmmaaaatttt LLLLiiiibbbbrrrraaaarrrryyyy CCCC++++++++ RRRReeeeffffeeeerrrreeeennnncccceeee MMMMaaaannnnuuuuaaaallll             IIIIFFFFLLLL((((3333))))



   IIIImmmmaaaaggggeeee ssssiiiizzzzeeee
     Image have four dimensions: _x, _y, _z, and _c.  The x and y dimensions are
     typically the width and height of the image although their interpretation
     is dependent upon the _o_r_i_e_n_t_a_t_i_o_n of the image (described below).

     The z dimension is generally interpreted as either depth for volume
     images or time for image sequences like movies; for 2D images the size of
     the z dimension is one.

     The c dimension is the channel or component dimension; the size of the c
     dimension is the number of components in each pixel.  The size of the c
     dimension must match the _c_o_l_o_r _m_o_d_e_l (see below) of the image.  For
     example, an RGB image must have a c size of three and a greyscale image
     must have a c size of one.  The only exception is the multi-spectral
     color model which can have any size for the c dimension.  The image size
     is represented by the _i_f_l_S_i_z_e structure defined in <_i_f_l/_i_f_l_S_i_z_e._h>.


   DDDDaaaattttaaaa ttttyyyyppppeeee
     The data type of an IFL image is the data type of the individual
     components of each pixel.  All components of a pixel must have the same
     data type.  The library supports nine data types: bit, signed byte,
     unsigned byte, signed short (16 bits), unsigned short, signed long (32
     bits), unsigned long, float (32 bits) and double (64 bits).  These data
     types are encoded by the _i_f_l_D_a_t_a_T_y_p_e enum defined in <_i_f_l/_i_f_l_T_y_p_e_s._h>.
     Typically, if a format actually stores data in say 4 bits per component
     the IFL interface to the file will present the data as unsigned char with
     a scaling range of 0-15 (see below).

     For a color palette image (see Color model section below), the image's
     data type refers to the type of its color index.  The type of the color
     map values is determined by the file format and stored in an iflColormap.


   DDDDiiiimmmmeeeennnnssssiiiioooonnnn oooorrrrddddeeeerrrr
     This is the relative ordering of the image's x, y and channel dimensions.
     There are three orderings supported by IFL:

          _i_n_t_e_r_l_e_a_v_e_d   channel dimension varies fastest, then x, then y, z
                        last; thus all the components of each pixel are
                        grouped together

          _s_e_q_u_e_n_t_i_a_l    x dimension varies fastest, then channels, then y, z
                        last; all the components of a single row are grouped
                        together (seldom used)

          _s_e_p_a_r_a_t_e      x dimension varies fastest, then y, then channels, z
                        last; the data is stored with each component isolated
                        in a separate plane.






                                                                        PPPPaaaaggggeeee 4444






IIIIFFFFLLLL((((3333))))            IIIImmmmaaaaggggeeee FFFFoooorrrrmmmmaaaatttt LLLLiiiibbbbrrrraaaarrrryyyy CCCC++++++++ RRRReeeeffffeeeerrrreeeennnncccceeee MMMMaaaannnnuuuuaaaallll             IIIIFFFFLLLL((((3333))))



     These orderings are encoded by the _i_f_l_O_r_d_e_r enum defined in
     <_i_f_l/_i_f_l_T_y_p_e_s._h>.


   CCCCoooolllloooorrrr mmmmooooddddeeeellll
     The color model of an image defines the interpretation of the components
     of its pixels.  There are 11 color models supported by IFL: greyscale,
     inverted greyscale (minimum is white, maximum is black), greyscale plus
     alpha, color palette (indicies mapped through a color map), RGB triplets,
     RGB plus alpha, HSV, CMY, CMYK, YCC and multi-spectral.  There are also
     component reversed versions of RGB and RGBA but their use is deprecated
     (they are for backward compatibility with older SGI systems).  These
     color models are encoded by the _i_f_l_C_o_l_o_r_M_o_d_e_l enum defined in
     <_i_f_l/_i_f_l_T_y_p_e_s._h>.


   OOOOrrrriiiieeeennnnttttaaaattttiiiioooonnnn
     The orientation of an image defines the spatial interpretation of its x
     and y dimensions.  It is defined in terms of the location of the origin
     of the image (one of the four corners) and the direction of the x and y
     dimension (whether x runs horizontally or vertically).  The combination
     of these two factors yields the eight orientations supported by IFL:

          _u_p_p_e_r-_l_e_f_t    origin in upper-left corner, x dimension is horizontal
                        (y is vertical)

          _u_p_p_e_r-_r_i_g_h_t   origin in upper-right corner, x dimension is
                        horizontal

          _l_o_w_e_r-_l_e_f_t    origin in lower-left corner, x dimension is horizontal

          _l_o_w_e_r-_r_i_g_h_t   origin in lower-right corner, x dimension is
                        horizontal

          _l_e_f_t-_u_p_p_e_r    origin in upper-left corner, x dimension is vertical
                        (y is horizontal)

          _r_i_g_h_t-_u_p_p_e_r   origin in upper-right corner, x dimension is vertical

          _r_i_g_h_t-_l_o_w_e_r   origin in lower-right corner, x dimension is vertical

          _l_e_f_t-_l_o_w_e_r    origin in lower-left corner, x dimension is vertical

     These orientations are encoded by the iflOrientation enum defined in
     <_i_f_l/_i_f_l_T_y_p_e_s._h>.


   CCCCoooommmmpppprrrreeeessssssssiiiioooonnnn
     The data in an image file may be compressed (depending on the format).
     Each format supported by IFL will automatically decompress the data read
     from the file when it is accessed through the iflFile methods ggggeeeettttPPPPaaaaggggeeee()
     and ggggeeeettttTTTTiiiilllleeee().  Similarly, each format will compress data passed to the



                                                                        PPPPaaaaggggeeee 5555






IIIIFFFFLLLL((((3333))))            IIIImmmmaaaaggggeeee FFFFoooorrrrmmmmaaaatttt LLLLiiiibbbbrrrraaaarrrryyyy CCCC++++++++ RRRReeeeffffeeeerrrreeeennnncccceeee MMMMaaaannnnuuuuaaaallll             IIIIFFFFLLLL((((3333))))



     sssseeeettttPPPPaaaaggggeeee() and sssseeeettttTTTTiiiilllleeee() methods before it is written out.  The
     compressions are encoded in the _i_f_l_C_o_m_p_r_e_s_s_i_o_n enum defined in
     <_i_f_l/_i_f_l_T_y_p_e_s._h>.


   PPPPaaaaggggeeee ssssiiiizzzzeeee
     Some images are stored in a paged manner, others are stored in horizontal
     strips, others may not allow random access at all.  Each file format
     encodes the underlying structure of its data with the page size
     attribute. The page size defines the dimensions of the natural chunks
     that an application can access with the getPage() and setPage() methods
     of iflFile.  For arbitrarily paged images the x and y page size may be
     smaller than the image's x and y size, requiring multiple fixed-size
     pages to be tiled across the image.  For strip oriented images the page
     width will be the same as the image width and the strips will be stacked
     vertically to cover the image.  For images that can't support random
     access to pages of fixed size, the page size will be the same as the
     image size; i.e. there will only be one page.

     The page size is defined by x, y, z and c dimensions as with the image
     size and follows the same rules with respect to the image's orientation.
     Data within each page is packed; there is no padding at the end of each
     line, even for bit data.  Some file formats may indicate such padding by
     having the page size wider that the image size.


   DDDDiiiissssppppllllaaaayyyy ssssccccaaaalllliiiinnnngggg rrrraaaannnnggggeeee
     Some image formats store a notion of the range of component values for
     purposes of scaling the data for display.  This attribute may not be
     present in an image, in which case the application should assume the
     range is the full range of values than can be represented by the image's
     component data type.  For images whose color model is iflRGBpalette this
     is the range of the entries on the color map, not the indices.


   SSSSttttaaaattttiiiissssttttiiiiccccaaaallll rrrraaaannnnggggeeee
     Some image formats store a notion of the statistical range of component
     values.  This range should not be used for display scaling purposes, but
     may be useful in some image processing computations.


   IIIICCCCCCCC pppprrrrooooffffiiiilllleeeessss
     Some image formats store an ICC (International Color Consortium) profile
     that can be used for color management.  See _h_t_t_p://_w_w_w._c_o_l_o_r._o_r_g for more
     details on the specifics of how such profiles are used.


TTTTHHHHEEEE IIIIMMMMAAAAGGGGEEEE FFFFIIIILLLLEEEE AAAABBBBSSSSTTTTRRRRAAAACCCCTTTTIIIIOOOONNNN
     IFL's mechanism for accessing image files is through the iflFile class.
     This class is used as a base for deriving all of the file formats
     supported by IFL. It provides static methods to open existing image files
     and to create new ones.  It provides methods to read and write image



                                                                        PPPPaaaaggggeeee 6666






IIIIFFFFLLLL((((3333))))            IIIImmmmaaaaggggeeee FFFFoooorrrrmmmmaaaatttt LLLLiiiibbbbrrrraaaarrrryyyy CCCC++++++++ RRRReeeeffffeeeerrrreeeennnncccceeee MMMMaaaannnnuuuuaaaallll             IIIIFFFFLLLL((((3333))))



     data, query all attributes and set some attributes.  Format specific
     operations are supported through the ggggeeeettttIIIItttteeeemmmm() and sssseeeettttIIIItttteeeemmmm() methods.
     Because of this base abstraction, IFL enables applications to be written
     that are image file format independent, yet still allows full access to
     unique attributes and capabilities of particular file formats.  Refer to
     the iflFile(3) man page for more details.


TTTTHHHHEEEE IIIIMMMMAAAAGGGGEEEE FFFFOOOORRRRMMMMAAAATTTT AAAABBBBSSSSTTTTRRRRAAAACCCCTTTTIIIIOOOONNNN
     The Image Format Library uses the iflFormat object to represent a
     description of the capabilities of a particular image file format. The
     iflFormat class provides a number of functions that can be used to look
     up formats by format name, by a file's "magic" number, or by file name
     extension (e.g. ".gif").  There is also a method to iterate through all
     available formats ( useful for user interfaces, for instance, to generate
     a menu of available file formats).

     The methods on an iflFormat allow the user to determine which values of
     the image attributes are supported by that format.  There are also
     methods to query the preferred values of those attributes.  See the
     iflFormat(3) man page for more details.


AAAADDDDDDDDIIIINNNNGGGG NNNNEEEEWWWW IIIIMMMMAAAAGGGGEEEE FFFFIIIILLLLEEEE FFFFOOOORRRRMMMMAAAATTTTSSSS
     To add support for a new image file format, you create a Dynamic Shared
     Object (DSO) that implements the format and add an entry in the IFL file
     format database for the format.

     The DSO implements the file format I/O itself and the IFL interface
     abstraction.  This is often done by using an already existing file format
     library and creating an IFL interface that makes calls into that library
     (see the iflJFIFFile.c++ and iflTIFFFile.c++ examples in ifl_dev.sw.gifts
     as examples of this).  The IFL interface is implemented by deriving
     classes from iflFormat and iflFile for the format.  Refer to the
     iflFile(3) and iflFormat(3) man pages for information on deriving your
     own classes.

     IFL uses a text database file to determine what file formats are
     available for use with IFL.  The database is normally located in the file
     /usr/lib/ifl/ifl_database but this may be overridden with the
     IIIIFFFFLLLL____DDDDAAAATTTTAAAABBBBAAAASSSSEEEE environment variable.


     The database is generated by the /usr/lib/ifl/ifldbgen program when new
     file formats are added to the system. To add you own file format, you
     should create a database file with the new entry or entries and place
     that file in the /usr/lib/ifl/database directory. Once there, running the
     ifldbgen program will generate the updated database. Unlike previous
     versions of IFL, you should not include an include directive in the new
     database file.  Doing so will result in conflicts when ifldbgen creates
     the new database.




                                                                        PPPPaaaaggggeeee 7777






IIIIFFFFLLLL((((3333))))            IIIImmmmaaaaggggeeee FFFFoooorrrrmmmmaaaatttt LLLLiiiibbbbrrrraaaarrrryyyy CCCC++++++++ RRRReeeeffffeeeerrrreeeennnncccceeee MMMMaaaannnnuuuuaaaallll             IIIIFFFFLLLL((((3333))))



   BBBBuuuuiiiillllddddiiiinnnngggg yyyyoooouuuurrrr DDDDSSSSOOOO
     There are two critical things that must be done when you build the DSO
     for your file format.

          You must build your DSO using the C++ compiler so that the
          statically declared iflFormat derived object (see the iflFormat(3)
          man page for more info) will be automatically instantiated when the
          DSO is dynamically opened by IFL.

          The DSO version string must be 'sgi2.0' for IFL 1.1 and IFL 1.2 to
          recognize it as a valid file format DSO.

     An example command line to create a DSO for the TIFF format might be:

          % CC -mips3 -n32 -o libiflTIFF.so -set_version sgi2.0 -shared -all \
               iflTIFFFile.o -ltiff -lifl -lm

     The DSO would then normally be installed in /_u_s_r/_l_i_b_3_2 or some other
     directory that can be pointed to by the LD_LIBRARYN32_PATH environment
     variable.  If you wish your file format to be useable with both -32 and
     -n32 executables then you will need to build the DSO for each object
     style and install them in the appropriate directories.  See the ld(1) and
     rld(1) man pages for more details on DSO search paths.


   FFFFoooorrrrmmmmaaaatttt ooooffff tttthhhheeee ddddaaaattttaaaabbbbaaaasssseeee ffffiiiilllleeee
     IFL database files are text files made up of a list of "format"
     declarations.  A format declaration looks like this:

          format _f_o_r_m_a_t_n_a_m_e
            match          _m_a_t_c_h_r_u_l_e
            description    "_h_u_m_a_n-_r_e_a_d_a_b_l_e _d_e_s_c_r_i_p_t_i_o_n _o_f _t_h_e _f_o_r_m_a_t"
            dso            _n_a_m_e _o_f _D_S_O _f_i_l_e
            access         _s_u_p_p_o_r_t_e_d _a_c_c_e_s_s _m_o_d_e_s
            subsystem      _i_n_s_t _s_u_b-_s_y_s_t_e_m _c_o_n_t_a_i_n_i_n_g _t_h_e _D_S_O
            suffixes       _c_o_m_m_a-_s_e_p_a_r_a_t_e_d _l_i_s_t _o_f _f_i_l_e _n_a_m_e _s_u_f_f_i_x_e_s


     The format declaration must come first and declares the name of an image
     file format.  A format name is a one-word string and can be any legal C-
     language variable name.  Each format declaration must have a unique name.
     All attribute declarations that follow a format declaration may appear in
     any order and apply to that format until the next format declaration is
     encountered in the database file.  The match, description, and dso
     attribute declarations are required for every format.

     The _m_a_t_c_h declaration is a logical expression that determines whether a
     particular file is of the declared format.  A _m_a_t_c_h rule consists of a
     C-style logical expression made up of functions, comparison operators and
     parentheses.  The following C-language operators may be used in a MATCH
     expression:




                                                                        PPPPaaaaggggeeee 8888






IIIIFFFFLLLL((((3333))))            IIIImmmmaaaaggggeeee FFFFoooorrrrmmmmaaaatttt LLLLiiiibbbbrrrraaaarrrryyyy CCCC++++++++ RRRReeeeffffeeeerrrreeeennnncccceeee MMMMaaaannnnuuuuaaaallll             IIIIFFFFLLLL((((3333))))



          &&  ||  ==  !=  <  >  <=  >= ( )

     The == operator works for string comparisons as well as for numerical
     expressions.

     Numbers in a match expression may be expressed in decimal, octal, or
     hexadecimal notation.  Octal numbers are expressed with a leading zero,
     such as 0732.  Hexadecimal numbers are expressed with a leading `0x' such
     as 0xf03c.  Decimal number are expressed normally, but may not have a
     leading zero.

     The following expression functions are available:

     char(_n)         Returns the signed byte located at offset _n in the file;
                     range -128 to 127.

     long(_n)         Returns the signed long integer located at offset _n in
                     the file; range -2^31 to 2^31-1.

     short(_n)        Returns the signed short integer located at offset _n in
                     the file; range -32768 to 32767.

     string(_n,_l)     Returns the _l character long string located at offset _n
                     in the file.

     uchar(_n)        Returns the unsigned byte located at offset _n in the
                     file; range 0 to 255.

     ulong(_n)        Returns the unsigned long integer located at offset _n in
                     the file; range 0 to 2^32-1.

     ushort(_n)       Returns the unsigned short integer located at offset _n in
                     the file; range 0 to 65535.

     Typical match declaration examples are:

         match short(0) == 0x01da || short(0) == 0xda01

     or

         match long(0) == 0xffd8ffe0 && string(6,4) == "JFIF"


     The description declaration is a human-readable description of the image
     format.  Typical description declaration examples are:

         description "Kodak Photo CD image"

     or

         description "TIFF image"




                                                                        PPPPaaaaggggeeee 9999






IIIIFFFFLLLL((((3333))))            IIIImmmmaaaaggggeeee FFFFoooorrrrmmmmaaaatttt LLLLiiiibbbbrrrraaaarrrryyyy CCCC++++++++ RRRReeeeffffeeeerrrreeeennnncccceeee MMMMaaaannnnuuuuaaaallll             IIIIFFFFLLLL((((3333))))



     Descriptions should be relatively short as they are used as the labels
     for GUI components in some applications.

     The dso declaration specifies that name of the DSO that contains the code
     to read and/or write the format.  This name is typically specified
     without a directory path; instead, the environment variable,
     LLLLDDDD____LLLLIIIIBBBBRRRRAAAARRRRYYYY____PPPPAAAATTTTHHHH, is used to locate the DSO at run-time.

     The optional _a_c_c_e_s_s declaration determines what access modes are
     supported for the format.  Possible values are: "readonly", "_w_r_i_t_e_o_n_l_y",
     or the default, "readwrite".

     The optional subsystem _d_e_c_l_a_r_a_t_i_o_n _c_a_n _b_e _u_s_e_d _t_o _n_a_m_e _t_h_e _i_n_s_t _s_u_b-
     _s_y_s_t_e_m _t_h_a_t _s_h_o_u_l_d _b_e _i_n_s_t_a_l_l_e_d _t_o _o_b_t_a_i_n _s_u_p_p_o_r_t _f_o_r _t_h_e _f_o_r_m_a_t.  _T_h_i_s
     _n_a_m_e _i_s _i_n_c_l_u_d_e_d _i_n _e_r_r_o_r _m_e_s_s_a_g_e_s _w_h_e_n _t_h_e _D_S_O _f_o_r _a _f_o_r_m_a_t _c_a_n _n_o_t _b_e
     _o_p_e_n_e_d.

     The optional suffixes _d_e_c_l_a_r_a_t_i_o_n _l_i_s_t_s _a _s_e_t _o_f _f_i_l_e _n_a_m_e _s_u_f_f_i_x_e_s _t_h_a_t
     _w_i_l_l _b_e _u_s_e_d _t_o _d_e_t_e_r_m_i_n_e_d _w_h_a_t _f_o_r_m_a_t _a _n_e_w_l_y _c_r_e_a_t_e_d _f_i_l_e _s_h_o_u_l_d _u_s_e
     _w_h_e_n _t_h_e _f_o_r_m_a_t _i_s _n_o_t _s_p_e_c_i_f_i_e_d _i_n _a_n iiiiffffllllFFFFiiiilllleeee::::::::ccccrrrreeeeaaaatttteeee() _c_a_l_l.  _A _t_y_p_i_c_a_l
     _s_u_f_f_i_x_e_s rrrruuuulllleeee wwwwoooouuuulllldddd bbbbeeee::::

         ssssuuuuffffffffiiiixxxxeeeessss ....jjjjppppgggg,,,,....jjjjppppeeeegggg


     Comments may be placed in a database file by using the '!' character.
     The comment extends to the end of the line.

     Other files (like /usr/lib/ifl/ifl_database) can be included in a
     database file using the "#include" directive.  This directive uses the
     same syntax as the C preprocessor equivalent; the "#" must be the first
     character on a line and the filename must be enclosed in quotes or
     angle-brackets:

         #include "filename"

     or

         #include <filename>

     The filename must be an absolute pathname (i.e. it must start with a
     "/").


SSSSEEEEEEEE AAAALLLLSSSSOOOO
     iflFile(3), iflFormat(3), iflSize(3), IFL(1), <ifl/iflTypes.h>, IL(1)









                                                                       PPPPaaaaggggeeee 11110000